Type evolution, also referred to as the versioning of types, is an important aspect of a distributed environment or service oriented architecture (SOA).
Typically, an exchange of messages between two end points, such as between a server device and a client device, requires that the end points agree upon a format for the messages. A message format may otherwise be referred to as a “data structure” or a “type,” and these terms may be used interchangeably throughout this description.
A type is typically described in a neutral language, a non-limiting example of which is XML Schema. Extensible Markup Language (XML) is a meta-markup language that provides a format for describing structured data. XML is a tag-based language and, by virtue of its tag-based nature, defines a strict tree structure or hierarchy. XML is a general-purpose language for representing structured data without including information that describes how to format the data for display.
XML accommodates an immeasurable number of schemas. A schema is a set of rules for constraining the structure and articulating the information set of XML messages. A “message” is formatted text, and “schema” describes the data structures, shape, and content of XML messages that are valid for a given application. As schemas evolve, data exchanges between different end points, in the form of requests and responses are compromised. For instance, a server using a current generation of a schema may receive a request to validate a message, information, or an action from a client using a previous generation or version of the same schema, or vice-versa. The schemas used by the server and the client must be compatible with each other in order for the message, information, or action to be validated.
More particularly, for type programmers, it is expected that their types would evolve over time to add new features, delete old features, or fix bugs in existing features. Unfortunately, the interoperability of cross-generational types is uncertain without specifically programming a type to be backward-compatible or forward compatible. A backward-compatible type is able to validate messages using received data that is formatted in accordance with a previous version of the type. A forward compatible type is able to validate messages using received data that is formatted in accordance with a subsequent version of the type.